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This paper describes the network elements and administrative 
functions affected by the implementation of the new method of oper- 
ation for 800 Service. The new method of operation affected all 
existing network elements and required significant coordination of 
the implementation of the necessary modifications to meet the service 
dates. In addition, a new element being introduced into the network, 
called a Network Control Point (ncp), required the creation of a 
complete administrative plan. 

I. INTRODUCTION 

The 800 Service, which allows a customer to receive calls without 
charge to the calling party, has specific network and administrative 
methods of operation. In the previous paper on the 800 Service by 
Sheinbein and Weber, appearing in this issue of The Bell System 
Technical Journal, the change in the method of operation to use the 
Stored Program Controlled (spc) Network and the use of centralized 
data bases called Network Control Points (ncps) were discussed. With 
this new method of operation, the previous network and administrative 
methods were reviewed, adjusted, or totally changed. The network 
implementation involved changes in the type and characteristics of the 
Originating Screening Offices (osos), Signal Transfer Points (stps), 
ncps, trunking, routing, and overall coordination. The administrative 
changes primarily affected service provisioning, but they also had a 
significant impact on service maintenance, network maintenance, net- 
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work administration, and network management. Sections II and III of 
this paper describe these changes. 

II. NETWORK IMPLEMENTATION 

To structure the network for transition from conventional 800 Ser- 
vice routing to the new common-channel interoffice signaling (ccis) 
routing technique utilizing centralized data base translations, a plan 
with specific guidelines was established. A system letter was issued by 
AT&T to the Bell Operating Companies (bocs) describing the ccis 800 
Service operation, equipment requirements for network nodes, net- 
work trunking needs, and plans for pots routing. Specific dates were 
established for implementation activities and the bocs were advised to 
establish project teams to provide overall coordination. The primary 
members of these teams were the ccis coordinators for network 
implementation concerns and the 800 Service product managers for 
marketing and tariff activities. 

2. 1 Originating Screening Offices 

Earlier sections of this issue of The Bell System Technical Journal 
discussed the spc network and described the function of an Action 
Point (acp). To review, an acp is a switching office that has the 
capability to communicate with an ncp. The oso will perform the acp 
functions for 800 Service. Under the previous 800 Service routing 
arrangement, any switching office equipped with proper translation 
tables could function as an oso. However, in the spc network, ccis 
osos (800 Service acps) are required to have ccis capability to allow 
for initiating inquiry messages to a centralized data base for screening 
and translation. Initially, the only switching systems capable of pro- 
viding the ccis 800 function are No. 4 ess (equipped with Generic 4E4) 
and No. 4A ets (equipped with Generic 4XC2). No. 1 ess and 1A ess 
offices will be capable of ccis oso operation with Generics 1E7 and 
1AE7 planned for 1982 and 1983, respectively. 

In addition to updating software with the new generic, the 4A ets 
offices required hardware modifications. Upon receiving dialed 800 
Service calls, a sender must be able to function as a sender/outpulser. 
This means that the sender must be able to release and outpulse the 
terminating customer's DDD-routable number,* which was received 
from the ncp. This modification was required for all senders at a 4A 
ets/ccis office functioning as an oso. 

Upon establishing the number of ccis-osos, all operating telephone 
companies planned to establish the trunks that would route dialed 800 



* The number returned from the ncp is a network-routable but not a customer- 
dialable number. 

1 746 THE BELL SYSTEM TECHNICAL JOURNAL, SEPTEMBER 1 982 



Service traffic to these new osos. The prerequisite for a ccis oso was 
established requiring that it must function as a conventional oso prior 
to ccis activation. This requirement forced a reduction from the over 
200 available osos to approximately 124 that would be equipped for 
ccis and ccis-oso operation. 

2.2 Signal Transfer Point direct-signaling generics 

To perform the function of sending inquiry messages via ccis from 
acps to ncps, a new feature — direct signaling — was required in the 
signaling network. This feature necessitated a new generic in all Signal 
Transfer Points (stps). The new generic (4XS2 for those stps that also 
served as switching systems and 1stp2 for stand-alone stps) was first 
available in September 1979. Conversions to the new generic began in 
September 1979 and completed with all stps converted in April 1980. 

Direct signaling provides the capability for the stp to route messages 
based on the first six digits of the dialed number. Thus, for 800 Service, 
inquiry messages will be routed to the appropriate ncp via the ccis 
network, based also on the first three digits which are 800 followed by 
the nxx. 

2.3 Network Control Point 

Network Control Points (ncps) are centralized data bases that 
contain call-handling information to perform the band-screening func- 
tions (the determination of whether the call originated from an area 
subscribed to by the purchaser of the service) and translate the dialed 
800 number to a standard ten-digit DDD-routable number of the cus- 
tomer's destination. New features that will be introduced with this 
new method of operation are based on the ability of further expansion 
of the translation at the ncp. This expansion will allow different ddd 
numbers to be returned for routing based on customer's requested 
routing. The ncp is a 3B20D processor-based system described in 
more detail in other sections of this issue. The ncps are individually 
duplexed systems that are deployed in 800 Service in mated-pair 
arrangements. For 800 Service, each pair will contain the data base for 
a subset of 800-nxx codes. Each member of the pair, a duplexed 
processor, will perform translations for half of the data as its primary 
responsibility and will perform translations of the other half of the 
data only in case of failure of the mate. The mate contains a copy of 
the same data base information but performs its primary and second- 
ary functions in exactly the mirror images of the mate, i.e., what is the 
primary data in one processor is secondary in the other. Each processor 
is traffic-engineered to 50 percent of its capacity during normal oper- 
ation, which allows for carrying the total traffic (it and its mate) in the 
event of a mate failure. 

The ncps are connected to the ccis network via dedicated inter- 
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processor (I) links to an stp. The ncps are colocated with stps. For 
initial service to accommodate all 800 Service data base requirements, 
seven pairs of ncps were deployed: two pairs each at the St. Louis, 
Missouri, Dallas, Texas, and Denver, Colorado regional stps, and one 
pair at a new pair of stps within the Denver region. All ncps were 
installed, operated, and maintained by AT&T Long Lines. 

Installation of the initial ncps began during the fourth quarter of 

1980 and completed in September 1981. Cutover to service commenced 
on September 1, 1981 with the first two pairs in the St. Louis region, 
and completed with the seventh pair in the Denver region on Novem- 
ber 1, 1981. 

2.4 Trunking plans and POTS routing 

One of the major network benefits of ccis 800 Service is the ability 
to use DDD-routable translations and routing. As discussed in the 
Sheinbein and Weber paper, the use of a centralized data base for 
band screening and translation to a DDD-routable number allows the 
elimination of the Terminating Screening Office (tso) function in the 
network. Since tsos were located high in the network hierarchy, 800 
Service traffic was routed over trunk groups to class 1 or 2 switching 
offices and, in many cases, utilized final trunk groups. This routing is 
inefficient since the call must eventually terminate at the class 4 office. 
Eliminating the tso function allows traffic to be routed from the oso 
over high-usage trunk groups as directly as possible to the serving 
office, consistent with standard traffic engineering rules. 

To effect a transition from conventional to ccis routing of 800 
Service traffic, AT&T Long Lines had to plan additional trunking in 
the high-usage groups. These were engineered and provided in the 

1981 construction program. The removal of tso trunking is planned 
for in the 1982 construction program. 

Another factor in converting to DDD-routable numbers is the number 
assignment in the serving office where the customer's 800 Service 
terminates. In many offices, the line number used in conventional 800 
Service routing was assigned from the available numbers in the office 
nxx code. In these cases, this number is a ten-digit code, routable from 
anywhere in the network. However, in other locations where line 
numbers suitable for 800 Service were not available in the central 
office code, pseudo codes were established and the routing information 
for this code is only known at the tso, the serving office, and in some 
cases the intermediate office. As a result, completion to these numbers 
is only possible by routing through the tso. Therefore, the bocs and 
independent operating companies (iocs) had to assign a ten-digit DDD- 
routable number for these lines. This is now possible since the tens 
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block restriction on line assignments of the 800 Service conventional 
routing plan is eliminated with the new ccis/ncp technique. 

Conversion to DDD-routable numbers is under the control of the 
bocs and iocs for their respective territories. To effect this ddd 
routing, the boc and ioc needed to load the ten-digit number into the 
data base for translation from the dialed 800 number. For those 
locations where DDD-routable codes are used in conventional 800 
Service routing, this step occurred as soon as the ncps were activated. 
At locations where pseudo codes were used, local translation changes 
and, in some cases, wiring changes were required before the pots 
record could be activated at the data base. Therefore, a time period 
was allocated for bocs and iocs to complete conversion to DDD-routable 
numbers. The beginning of this period was determined by the activa- 
tion date of the ncp that contained the specific 800 nxx assignments 
(September 1 to November 1, 1981) and was completed by February 
1, 1982. This completion date was set since the 1982 trunking plan 
assumed that ddd routing was in effect and tso trunking eliminated. 

2.5 Cutover strategy 

Since 800 Service is national in scope, cutover to the new ccis 
operation without service impairment would be difficult. A plan was 
needed to allow the orderly activation of 124 osos and 14 ncps. The 
plan was centered on the ability of an stp, whose ncp is not yet 
installed, to turn around inquiries, destined to the ncp, back to the 
ccis-oso. The format of the response looks to the ccis-oso as if it 
came from the ncp, except that a DDD-routable number is not yet 
available. The St. Louis, Dallas, and Denver stps were initially 
equipped with the turnaround translation to return the dialed 800 
number to the oso. 

As discussed previously, after February 1982, the ncp will contain 
only DDD-routable numbers. However, during the transition, the ncp 
or the stp may return an 800 number, and special arrangements to 
handle such responses were devised. Upon receiving an 800 number as 
a response to a data base inquiry, the osos will revert to conventional 
800 Service operation and route the call to the appropriate tso for 
completion. Activation of the ccis-oso function at osos began in May 
1980 and continued each weekend until August 1981. All stp locations 
were equipped with 800-xxx routing information to direct inquiries to 
the proper stp and, thus, the ncp location. This step was completed in 
the second quarter of 1980. 

The final step in cutover to ccis 800 Service occurred during the 
September-November 1981 period with activation of the ncps. Prior 
to this time, the normal installation procedures and acceptance testing 
took place and the operational responsibility of the processor was 
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officially turned over from Bell Laboratories to AT&T Long Lines. 
Loading to the data base occurred during the two weeks immediately 
preceding cutover. Service activation of the ncp occurred by activating 
the I-links to the stp and removing the 800 turnaround feature. All 
inquiries were then routed to the ncp for data base translation. 

2.6 Coordination of implementation activities 

The implementation of ccis 800 Service required the close coordi- 
nation of activities of a large number of organizations. In addition to 
the normal first application support activities performed by Bell Lab- 
oratories and Western Electric, coordination between AT&T, Long 
Lines, and the bocs was vital to an orderly implementation. To provide 
this coordination, an 800 Service Network Implementation Committee 
was formed in October 1980. The committee, under the chairmanship 
of a representative of AT&T Network Design, consisted of represent- 
atives from various AT&T Network departments, Long Lines, Bell 
Laboratories, and Western Electric. This committee, which met 
monthly, was charged with monitoring the implementation progress of 
all network activities for ccis 800 Service. This included identifying 
critical issues and taking corrective actions, coordinating all network 
activities, monitoring ncp installation progress, and providing central 
project control. 

III. ADMINISTRATIVE FUNCTIONS 

Development of a new 800 Service capability within the network 
necessitated careful study and definition of the needs of a Bell System 
operational environment. The operational plan must adequately sup- 
port both the services that would utilize the capability and the network 
entities that would provide the capability. The administrative plan for 
the 800 Service capability encompassed five primary operational func- 
tions: 

• Service Provision — The process that includes the tasks performed 
from the time a customer orders service to the time the service 
has been installed in the network and made available for the 
customer's use. 

• Service Maintenance — The process invoked by a report of im- 
paired service, initiated either by a telephone company (boc, ioc, 
AT&T Long Lines) procedure or by a customer report, that covers 
the tasks of verifying, sectionalizing, and repairing the reported 
troubles. 

• Network Maintenance — The process, peculiar to specific elements 
in the network, that guides the analysis of a problem, localization 
of trouble, and repair of that specific element. This process is 
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either keyed by a self-diagnostic alarm condition of the element or 
is triggered by service maintenance procedures. 

• Network Administration — The set of tasks associated with moni- 
toring the performance of elements in the network to ensure 
optimizing the load-handling capability of each element. 

• Network Management — The process that monitors indications of 
abnormal network operation and supports the implementation of 
controls that will minimize total network harm. 

Since 800 Service was an existing Bell System offering, there was 
already in place an operational set of methods, procedures, and tools 
that covered all of the above functions. The challenge of developing an 
administrative plan for 800 Service capability was not to create a total 
set of processes from the ground up but, rather, to identify the unique 
functional requirements in a manner that would blend with the existing 
operational environment. With this as an objective, a functional anal- 
ysis of the total set of administrative needs was conducted. The results 
of that analysis indicated that the aspects of network maintenance, 
administration, and management that were related to the acps and 
the stps could readily be applicable to the work centers and operations 
systems that were already responsible for those network elements. 
Since the ncp was being initially introduced into the network, a 
complete administrative plan covering network maintenance, admin- 
istration, and management had to be created for this new element. 

The functional analysis also indicated that major augmentation of 
the provision and maintenance processes for 800 Service would be 
required to accommodate the new methods of call routing that were 
being introduced by the ccis-800 Service capability. The remainder of 
this paper will focus on the administrative plan developed for the ncp 
and on the new aspects of service provision and maintenance that will 
apply to the range of services that utilize the ccis-800 Service capabil- 
ity. 

3. 1 Service provision process 

As described in other papers in this issue of The Bell System 
Technical Journal, the major change in the network architecture was 
the introduction of the ncp and its related translation data base. The 
data base contains, for each 800 number, the following specific param- 
eters required to successfully complete a call initiated to the 800 
number: 

(i) Valid originating area codes based on purchased area 
(ii) POTS number translations for interstate and intrastate calls 
(Hi) Desired translations based on particular time of day or day of 
week 
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(iv) Alternative translations based on busy condition of primary 
line. 

Obviously, the source of this information is the 800 Service customer. 
The primary new task in the service provision process is to capture 
that information and condition and place it in an ncp data base (and 
its mate data base). Procedures existed in each boc and ioc to generate 
service orders, institute billing procedures, and ensure that the physical 
installation of the service took place. A key work group in those 
procedures was the Dialing Service Administration Center (dsac), 
formerly called inwats coordinators. The role of the dsac was ex- 
panded to include the responsibility of deriving from a service order 
the information that would have to be provided to the ncp data base 
for 800 Service. To assure the integrity of that information, transform 
it to a form usable by the ncp, and deliver it to the proper ncp, a 
centralized Bell System Operations System was designed by AT&T 
Long Lines. The system, designated as the Network Support System- 
800 Service (nss-800), provides on-line, dedicated access by each dsac 
location. The dsac interacts with the system to obtain and reserve 
unique 800 numbers. When a service order is issued, the dsac again 
interacts with the system to enter required information about the 
service and a service date. These data are validated as they enter the 
system. Within nss-800, a customer profile record is created. Twenty- 
four hours prior to the service date, nss-800 will retrieve the customer 
profile record, format it for the ncp, determine the primary and mated 
ncps that are to receive the record, and load the record into the 
appropriate ncps. The nss-800 is connected via dedicated 4800-baud 
private lines to every ncp in the network. The system will look for an 
acknowledgment from both ncps (primary and mate) to ensure that 
the record was properly distributed. If both acknowledgments are not 
received, the system will alert the work center responsible for ncp data 
administration. That work center is the Operations Network Admin- 
istration Center (onac), a Long Lines Network Services work group 
located in Kansas City, Missouri. The onac was created to coordinate 
the overall flow of service provisioning information from the dsac 
organizations, through nss-800, to the ncps. The onac is responsible 
for managing that information flow and ensuring that any malfunctions 
in the flow are promptly repaired. In addition to this role in the service 
provision process, onac provides an important ingredient to the service 
maintenance process. 

3.2 Service maintenance procedures 

The placement of translation data bases throughout the network 
offers the potential for a customer-affecting trouble caused by a data 
record error. The previously existing maintenance plan for 800 Service 
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was expanded to include procedures that would effectively locate and 
clear possible data-related problems. Customer trouble-reporting pro- 
cedures remained unchanged, being handled either by Special Service 
Centers (sscs) or Repair Service Bureaus (rsbs). These centers will 
use existing procedures to verify, sectionalize, and clear physical plant 
problems. If it is ascertained that the customer reported problem could 
be data-related, the responsible work center (ssc or rsb) will contact 
their local dsac and request their assistance. The dsac has direct 
access on the nss-800, and through on-line inquiry, it can audit 
customer record content, as well as determine which version of the 
record is contained in the ncp data base. If discrepancies are discov- 
ered, dsac can transmit immediate corrections to ncps through nss- 
800. The onac has access to additional capabilities in nss and, accord- 
ingly, the dsac may contact onac and request their assistance on more 
difficult troubles. 

In addition to serving as the tool that dsac and onac can utilize to 
respond to trouble reports, nss-800 is programmed to periodically 
audit the contents of the ncp data base. The nss-800 retrieves each 
record in the primary data base and mate data base and compares 
them with the current active record entered by dsac. Any discrepancy 
discovered in this comparison is reported to onac for reconciliation. 

3.3 Network management 

As mentioned above, nss-800 is directly linked to each ncp to allow 
real-time data interactions between the ncps and onac and the dsacs. 
The nss-800 also serves to link the ncps to the Network Operations 
Center (noc) in Bedminister, New Jersey, so that the network man- 
agement aspects of the ccis-800 Service capability can be monitored 
and, if necessary, controlled in the case of mass calling to any 800 
number. The ncp data base has been designed with automatic control 
capabilities that monitor attempts to each 800 number, compare those 
attempts against a threshold value and, when necessary, instruct osos 
to limit the volume of calls directed to that 800 number. When this 
control is initiated by an ncp, a message is sent to the noc via the nss- 
800. Thus, the noc is alerted to the calling conditions occurring on the 
network. The noc personnel can assess overall network performance 
and, based on their analysis, can elect to override the controls initiated 
by the ncp. 

As described above, the nss-800 and the onac provide the primary 
augmentation to the service provision and service maintenance proc- 
esses to support the ccis-800 Service capability. In addition, nss-800 
supplies the noc interface to the ncps to support the network man- 
agement process. While the system was developed primarily to satisfy 
these functions, its role in several adjunct functions was identified. 
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Since the system became the collector of all 800 Service customer 
records, it was the logical source of information for the 800 Service 
Directory Assistance (da) process. A mechanized interface was devel- 
oped between nss-800 and the 800 da processor in Kansas City, 
Missouri. Each night, record changes that have been entered into nss- 
800 by the dsacs are transmitted to the da processor where they are 
conditioned and forwarded to the 800 Service da centers. 

The nss-800 also provides a mechanized interface to the Centralized 
Message Distribution System (cmds) in Kansas City. The information 
provided is the correlation between an 800 number and the translation 
that will exist in the network. This correlation is necessary for cmds to 
correctly provide source data for the traffic engineering processes that 
it supports. 

3.4 Network Control Point maintenance 

The introduction of the ncp as a new network element required the 
development of a maintenance and administration plan for that entity. 
The basic design of the ncp, similar to other spc-based elements, 
included self-diagnostic and self-repair capabilities. Primary interfaces 
for local craft personnel and for the No. 2 Switching Control Center 
System (2-sccs) were provided. Because of the close relationship 
between the ncp and the ccis network, it was desirable to provide ncp 
performance information to the work centers responsible for ccis 
network performance. These centers are the ccis Electronic Switching 
System Assistance Center (cesac) located in Columbus, Ohio, and the 
zonal cesacs located in San Francisco, California; Denver, Colorado; 
Chicago, Illinois; and White Plains, New York. The centers are pro- 
vided access to the data they need via a centralized Bell System 
Operations System, designed by AT&T Long Lines, called the Network 
Control Point Administration System (ncpas). The ncpas is directly 
linked to every ncp in the network and collects processor performance 
data from each ncp. These data are stored and formatted into reports 
that can be retrieved by cesac and zonal cesacs. The reports are also 
received by the local craft personnel at each ncp location. The local 
craft personnel can be connected to ncpas through the ncp itself. This 
arrangement removes the burden of formatting and storing report data 
from the ncp and provides the users with the flexibility to redefine 
report structure and content without incurring ncp development cost. 

3.5 Network Control Point administration 

Administration of the ncp processors encompasses two discrete 
functional processes. The first of these is definition of the software of 
each ncp: What service will the ncp be expected to handle (800 Service, 
Automated Calling Card Service, etc.) and what customer records 
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(800-nxx, npa-nxx) will it contain? This software definition is con- 
tained in the ncps "specification file." These decisions are made in an 
engineering process and provided to a national Long Lines work center, 
the Engineering Network Administration Center (enac). The en AC 
uses the ncpas to structure the specification files for each ncp, format 
them, and distribute them to the ncps involved. Once the service 
specification has been distributed in this manner, there is a second 
function, the complementary administrative function, to be performed. 
Since the distribution of services and records among the ncps is based 
on a forecast, it is necessary to monitor the actual call attempts that 
each ncp is handling to ensure that the engineering distribution is 
correct. The ncpas is the vehicle used by enac to perform the 
monitoring function. When redistribution is appropriate, enac will use 
ncpas as described above. 

3.6 Traffic measurement collection 

Embedded in the design of the ncp software is the capability to 
measure various attributes of the call attempts handled by each ncp. 
These data are valuable to the engineering or network provisioning 
and marketing processes that evaluate various aspects of a service 
offering. There is also a requirement to capture network usage statistics 
that will be used in the separations process. Although the ncp collects 
these types of data, it cannot analyze them. Accordingly, AT&T Long 
Lines developed a national Bell System Operations Support System 
called the Network Control Point Data Collection System (ncpds). 
This system is linked to each ncp and collects the traffic measurement 
data generated by the ncps. Sampling rates for the particular data to 
be captured by each ncp are set by onac and enac using nss-800 and 
ncpas, respectively. The ncpds serves as a centralized data store that 
can provide the information needed by engineering and marketing 
processes. 

3.7 800 Service record 

At the time of implementation of the 800 Service capability using 
the spc network, there were almost 200,000 customer lines for 800 
Service. Records pertaining to each of these lines had to be verified, 
expanded to include valid pots translations, and then loaded into the 
appropriate ncp data base. The source data for these records was 
resident in the bocs and iocs and existed in various forms and states 
of accuracy. The transformation of these data to a validated and 
consistent form that could be loaded into the ncps represented a 
substantial task for the Bell System. To effect the necessary controls 
on the conversion process and to minimize the manual work effort, 
AT&T Long Lines developed a mechanized process that utilized two 
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existing 800 Service data records, Wide Area Telecommunications 
Services (wats) Information System, and 800 Directory Assistance, 
plus a mechanized record of 800 numbers from those bocs and iocs 
that had one available. These records were compared and used to 
develop an initial load of the nss-800 data base. Various reports 
indicating discrepancies resulting from the comparisons were furnished 
to each involved boc and ioc. The nss-800 was made available in 
December 1980 to all the bocs and iocs to allow them to complete and 
purify their records. All on-going service-order activity was entered 
into nss-800 to build as complete and accurate a data base as possible 
before actually loading the ncp data base. 

3.8 Network Support System-800 characteristics 

The nss-800 is implemented on a large-scale IBM main frame (3032) 
computer located in Rochelle Park, New Jersey. The machine is 
dedicated to the nss-800 application. In addition, a second processor 
(IBM 3168) is available to sustain the system functions required to 
interface with the ncps if there is a failure of the primary processor. In 
the unlikely event of a catastrophic processor failure at Rochelle Park, 
full-scale remote site restoral capability is provided in White Plains. 
The system uses the Information Management System (ims) data base 
management/ teleprocessing software package from IBM. Each line 
between nss-800 and an ncp has a dedicated backup. These lines are 
all terminated on a COMTEN 3650 front-end National Cash Register 
processor that has been designed to support the BX.25 level 1, 2, and 
3 protocol. 

3.9 Network Control Point Data Collection System characteristics 

This application has been implemented on the nss-800 backup 
processor described above. Data related to 800 Service and its cus- 
tomers is fed indirectly to ncpds from the ncps via an ims EXIT 
routine in the nss-800. Processor traffic measurement data are fed 
from the ncps directly to ncpds. The COMTENs terminate simplex 
lines from ncp. This arrangement efficiently uses the processing power 

that has been provided at the Rochelle Park site. 

3.10 Network Control Point Administration System characteristics 

The ncpas is implemented on two DEC 11/70 processors located in 
Freehold, New Jersey. Both processors utilize the UNIX* operating 
system. One processor acts as a front-end, handling the communica- 
tions interface to the ncps (duplex lines) and supporting the BX.25 



* Trademark of Bell Laboratories, Inc. 
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level 1, 2, and 3 protocols. The second processor handles the network 
administration applications. The enac, located in Cincinnati, Ohio, is 
connected to ncpas, and the zonal cesacs are provided with dial-up 
capability. 

3.11 Center and system impact 

While the introduction of the ncp and its translation data base has 
a dramatic effect upon the capabilities of the network, the impact on 
the operational environment required to support those capabilities was 
minimized. Two new national work centers (onac and enac) were 
identified, the role of dsac was expanded, and three centralized oper- 
ations systems were developed. The functions of both the centers and 
systems are intended to be consistent with the network capabilities. 
While the initial implementations are geared to 800 Service, the design 
of both the centers and systems is hoped to easily accommodate any 
new customer services that employ the spc network capability. 

IV. SUMMARY 

The technical implementation of the ccis 800 Service required 
modifications in all existing call-processing elements, as well as the 
addition of the new network element, the ncp. The administrative 
implementation affected service provision, maintenance, network ad- 
ministration, and network management. Clearly, such a new capability 
impacts how we provide service today and required the coordination 
of all elements of the Bell System-Bell Laboratories, AT&T, AT&T 
Long Lines, Western Electric and, most critically, the bocs, as well as 
the iocs. Without their cooperation, such a network capability could 
not have been implemented. 
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